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This article describes the issues involved in operator services 
planning and the structure of the computer tools developed to address 
these issues. The approach to long-range planning of operator ser- 
vices networks is very flexible, and the availability of the Traffic 
Service Position System No. IB further enhances this flexibility. This 
planning effort is a complex process that has been automated by 
computer tools that are both accurate and user-friendly. 

I. INTRODUCTION 

The planning of Traffic Service Position System (TSPS) installa- 
tions and growth is rather different from that usually encountered in 
engineering central office equipment. 1 One of the reasons for this is 
the great flexibility that the engineer has in selecting the placement of 
operator position subsystems and how traffic will be routed to the 
various TSPSs that serve a particular area. The availability of the 
TSPS No. IB offers new choices: formerly, when a TSPS exhausted 
its call processing capacity the alternatives were to divert the traffic 
overload to another TSPS that had surplus capacity or to purchase a 
new TSPS and divert load to it. Under the new system a TSPS No. 1 
can be retrofitted to a TSPS No. IB with much greater call capacity. 2 
The resulting efficiencies, including avoidance of trunk rearrange- 
ments, trunk splintering, and opening of new operator groups, provide 
significant economic benefits to the operating telephone company. The 
TSPS No. IB also provides the engineer more opportunities to con- 
solidate, that is, to retrofit a subset of a group of TSPS No. l's to 
TSPS No. lB's and retire some or all of the remaining TSPS No. l's 
in the group. 
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The Operator Services Traffic Network Planning System (OSTNPS) 
is a tool designed to aid telephone companies in making long-range 
plans for TSPS and related network evolution in order to guide short- 
range planning activities. 3 OSTNPS has been available to telephone 
companies since November 1981. Using interactive programs and a 
UNIX* operating system environment, OSTNPS lets the user make 
the critical decisions while taking over the detailed calculations that 
can often severely limit the number of alternatives that a planner 
considers. OSTNPS combines maximum user flexibility with fast turn- 
around: the user can generate and analyze an alternative satisfying all 
the necessary constraints in about two hours of terminal time (CPU 
time is negligible). Since a typical alternative may involve 45 nodes 
and an associated network configuration over a 20-year period, design 
considerations and human factors engineering were of the utmost 
importance in developing OSTNPS. 

Many of the factors to be considered existed for the TSPS No. 1 
before the development of the TSPS No. IB; the general approach 
taken with the program design made addition of the new degree of 
freedom relatively simple. This article describes the problems involved 
in planning TSPSs, and the software programs developed to guide the 
user in this planning. 

II. PLANNING ISSUES 

2.1 Long-range planning 

The purpose of long-range planning is to evaluate the results of the 
most likely trends in traffic, services, and technology in order to 
optimize the long-term results of short-range decisions. The usual long- 
range plan covers a period of 20 years. The procedure consists of 
generating a set of alternatives and comparing the economic worth of 
each. The alternatives usually include a continue-as-is base plan with 
which the other alternatives are compared. 

Because 20-year forecasts involve many potential contingencies, the 
long-range planner must apply judgment and experience to select the 
most reasonable alternatives and to perform appropriate sensitivity 
analysis on these alternatives. 

2.2 Operator services long-range planning issues 

The choices specific to operator services include the following. 

2.2. 1 Purchase of new nodes 

Usually the purchase of a new TSPS, Remote Trunk Arrangement 
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(RTA), or Position Subsystem (PSS) is made to relieve the exhausts 
of existing nodes. 4 The planner must decide where to place the new 
node and where its traffic is to come from. For example, a new TSPS 
may be loaded in such a way as to delay its exhaust and that of 
neighboring systems for as long as possible, or it may be placed in a 
way such that its resultant traffic is routed over facilities that are as 
short as possible. Usually a new PSS is placed where there is a large 
operator labor market. The issues involved in an RTA purchase will 
be discussed in Section 2.2.4. 

2.2.2 Retrofit to TSPS No. IB 

A TSPS No. IB has greater real-time and memory capabilities than 
a TSPS No. 1. If the TSPS No. 1 exhausts real time or memory, then 
the savings in rearrangements and/or new node purchases must be 
weighed against the costs of retrofit and, in a growth environment, the 
eventual purchase of a new node. 

2.2.3 Load balancing 

Load balancing consists of moving trunks, and hence traffic, from 
one node to another in such a way that all exhausts are relieved. Load 
balancing eliminates the capital expenditure of a new operator node in 
the given year, but the purchase is only deferred and load balancing 
can be quite expensive in itself because of trunk rearrangements. 

2.2.4 RTA Issues 

An RTA concentrates trunks and homes them in on a nearby TSPS 
via base-remote (BR) trunks. 4 The planning issues specific to RTAs 
are as follows. 

• Direct versus RTA trunking. If a set of local offices is located a 
long distance (say 100 miles) from the TSPS on which the offices 
are to be homed, one alternative is to trunk them directly to the 
TSPS and another is to concentrate these trunks via an RTA. In 
the former case, trunk and facility costs dominate; in the latter, 
purchase of an RTA is necessary. In general, purchasing an RTA 
is desirable if many trunks are involved and the distance to the 
TSPS is large. 

• Colocated RTA. If a TSPS reaches a condition of trunk exhaust, 
an RTA may be purchased and colocated with the TSPS: the 
RTA concentrates some of the TSPS incoming trunk calls and 
relieves the exhaust. Further, a colocated RTA-TSPS pair gives 
more flexibility in load balancing if the TSPS later becomes 
exhausted for any other reason: the RTA could then be rehomed 
on a nearby TSPS with spare capacity. An RTA rehome is defined 
as a move of its base-remote trunks; if the RTA were not there, a 
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move of about eight times as many TSPS incoming trunks would 
be necessary. 

2.2.5 PSS rehoming 

TSPS operators are assigned to PSSs, consisting of groups of oper- 
ator consoles and the associated intelligence. 4 A move involving TSPS/ 
RTA traffic usually means that position requirements at that TSPS 
will change. If a sufficient amount of traffic is moved from one TSPS 
to another, one or more PSSs may be rehomed between these TSPSs. 
The planner generally has great flexibility in these rehomings except 
for mileage constraints. 

2.2.6 Impact on toll trunking 

Sometimes a move of TSPS/RTA traffic impacts on toll trunking as 
well. Since TSPS and RTA incoming trunks are bridged between the 
local office and toll switch, a move of these trunks implies a correspond- 
ing connect/disconnect of trunks at the associated toll switches. More- 
over, such a move will also cause a change in intertoll trunking. Every 
local area generates operator traffic that returns to itself via the toll 
switch. When TSPS/RTA incoming trunks are moved from one toll 
switch to another, the traffic must have a path from the second toll 
switch back to the first via Direct Distance Dialing (DDD) trunks. 
This path would not have been necessary had the move not taken 
place. On the other hand, an RTA rehome does not change toll 
trunking since only BR trunks are involved. Detailed examples of 
these issues will be considered in Section IV. 

2.3 New considerations with TSPS No. 1B 

A TSPS No. 1 that exhausts real time or memory can be relieved by 
retrofitting a 3B20D Processor in place of the present Stored Program 
Control No. 1A— a procedure that converts TSPS No. 1 to TSPS No. 
IB. 2 The demand for the 3B20D Processor for TSPSs existed because 
real time or memory is the limiting factor on most TSPSs today. From 
a planning point of view, this method of relief is easiest because no 
traffic rearrangements are needed. 

2.3. 1 Selective conversionjo TSPS No. 1B 

Because of capital constraints, a planner may convert some but not 
all exhausted TSPS No. l's to TSPS No. IB in a given year. This 
strategy introduces new effects on planning: a combination of conver- 
sion to TSPS No. IB, TSPS/RTA purchases, and load balancing may 
take place. Consider the following example. Suppose that both TSPSs 
A and B (both TSPS No. l's) exhaust real time in some study year 
and that a single conversion to TSPS No. IB is to be made in that 
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year. The planner retrofits A, giving it extra real-time capacity. To 
relieve B, the planner takes the following steps: two RTAs are pur- 
chased, colocated with B, loaded with incoming trunks from B, and 
homed on A. B is thus relieved and survives real-time exhaust two 
more years, at which time B is retrofit and the RTAs are rehomed 
back to B. 

2.3.2 TSPS consolidation 

Planning issues are different in low-growth regions: the added real- 
time capacity of TSPS No. IB increases the possibility of TSPS 
consolidation. First a consolidation candidate must be selected from a 
group of nearby TSPSs. It may be the oldest, most centrally located, 
or most lightly loaded TSPS of the group. The TSPS is retired by 
moving all of its traffic to the other TSPSs in the group. After 
consolidation, the remaining TSPSs may have to be converted to 
TSPS No. IB earlier than if consolidation had not taken place, since 
they will exhaust sooner. 

III. USER-CONTROLLED PLANNING TOOL 

3. 1 Design considerations 

OSTNPS was developed so as to combine extreme flexibility with 
very fast turnaround. Extreme flexibility means that the user can 
generate any alternative desired — the programs check that no con- 
straints are violated along the way. Very fast turnaround means that 
the input database and modeling must be both representative and 
simple, so that generation and analysis of an alternative can be done 
in an hour or two. A typical operator services alternative consists of 5 
TSPSs, 8 RTAs, 20 PSSs, and a dozen toll switches all evolving as a 
function of time with consolidation, purchase of new nodes, or load 
balancing. The usual study period is 20 years so that, with a base year, 
there may be up to 21 toll-connect and intertoll sets of trunk require- 
ments ("trunk fields") associated with the alternative. A typical num- 
ber of such solutions is ten. 

OSTNPS does not optimize but rather lets users generate their own 
alternatives. For a given study area, it is not known how close a given 
plan is to the optimum because the optimum is not known to begin 
with. However, analysis of all possible alternatives for a given simple 
study area suggests that the economic worth of a typical "intelligent" 
user plan will be within 5 percent of the optimal plan. 

3.2 Modeling considerations 

Modeling considerations are as important as design considerations, 
because inputs must be at once representative and simple if the 
objective of fast turnaround is to be met. 
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3.2.1 Input database 

For mechanized long-range planning, it is desirable to obtain reason- 
able results using data that are easy for users to collect. OSTNPS 
requires comparatively little user input data, and all data come from 
standard sources. Implied in the small size of the input data base are 
several assumptions — summarized below — used to make forecasts. 

The input database contains only three types of call volumes: total 
trunk seizures on TSPS (whether or not an operator is accessed), trunk 
seizures that reach an operator for any purpose, and trunk seizures 
that reach an operator only for Operator Number Identification (ONI) 
of the calling party. These three volumes, for every TSPS and study 
year, are the primary inputs into all of the forecasting algorithms. 

Some of the algorithms are linear regressions based on these vol- 
umes. One such regression forecasts required operator consoles (posi- 
tions), the independent variable in this case being the product of the 
number of attempts reaching an operator and the average operator 
work time per call (both input database items). In reality, the relation- 
ship is not quite linear because large operator teams are more efficient 
than small operator teams. However, this lack of linearity occurs 
primarily in lightly loaded TSPSs; for moderately to heavily loaded 
TSPSs, a linear relation is sufficient. 

Simplifying assumptions are also made in modeling the required 
TSPS trunks. First, minor trunk types are considered as a single 
category, a simplification that cuts down required input data consid- 
erably. Second, for each trunk type considered by the program, it is 
assumed that groups are of equal size, and that each group handles the 
same number of attempts with the same holding time per attempt. 
The average trunk group size is an input item, and the holding time is 
derived from input items. These approximations are quite suitable for 
long-range planning, and because of them, the input database is made 
far easier for the user to create. 

3.2.2 Network 

Even though OSTNPS is fundamentally an operator node planner, 
there must be a way to estimate the cost of trunk movements resulting 
from shifts in loads. Trunk movements occur in the toll-connect and 
intertoll fields. In the toll-connect field, it is adequate to assume that 
when a deload occurs, the appropriate number of trunks are discon- 
nected from the deloaded operator node and the same number recon- 
nected to the other (if the two operator nodes are colocated, the costs 
are different than if they are not, and this is properly taken into 
account). This information, together with percentages of 2- wire and 4- 
wire bridges, facilities, and average mileages between the local offices 
and toll switches before and after, is sufficient to get a good estimate 
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of the toll-connect movement costs. Intertoll movement also occurs 
after a deload since the load on all toll switches is affected, depending 
on community of interest. It would be unnecessarily complex to reen- 
gineer the toll network after each deload or purchase. Instead, the 
change in offered load between every pair of toll switches is estimated 
and converted to trunks. Because intertoll trunk groups are generally 
larger and thus more efficient than toll-connect trunk groups, it is 
assumed that an intertoll trunk carries twice the load as a toll-connect 
trunk. 

IV. STRUCTURE OF PROGRAMS 

4.1 Introduction 

The job of generating and evaluating a long-range operator services 
alternative can be split into four separate tasks, each programmed as 
a separate OSTNPS module. Figure 1 shows a general flowchart of the 
process, and Fig. 2 illustrates the scope of each of these programs in 
the overall operator services network. 

(i) Node exhaust. The Node Exhaust program calculates require- 
ments for each TSPS/RTA node in each year, informs the user about 
possible exhausts, and lets the user relieve the exhausts by purchasing 
new nodes, moving traffic, or converting to TSPS No. IB. This program 
does not involve itself with the network connecting the nodes — this 
task is performed later. 

(ii) PSS. The PSS program, given overall position requirements 
from the Node Exhaust program, assigns specific PSSs for these 
requirements and builds the network joining those PSSs to the TSPSs. 

(Hi) Remainder of network. The Network program assigns specific 
trunk groups between local areas, TSPS/RTA's, and toll switches. As 
discussed in Section 4.4, the detailed network can be reconstructed 
given the global requirements output by the Node Exhaust program 
for each TSPS/RTA. 

(iv) Translation for Economic Analysis. The Translator program 
combines the output of the preceding two programs and transforms it 
into a "network file" for the economic evaluator program TASP (Toll 
Alternatives Studies Program). 5 TASP, a very detailed economic eval- 
uator based on Capital Utilization Criteria (CUCRIT), requires a user- 
supplied "cost file" as well as the above network file. 

Following is a detailed description of each of these programs. 

4.2 Node Exhaust program 

4.2.1 Summary 

The Node Exhaust program is the first module of OSTNPS. Starting 
with a set of user-supplied input data describing the operator nodes 
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Fig. 1— Flowchart of OSTNPS. 

(TSPSs and RTAs) in the study area, the program generates part of 
an alternative interactively. The alternative is refined further in suc- 
ceeding OSTNPS modules. Figure 3 shows a general flowchart of the 
Node Exhaust program. 

For each study year, the program forecasts requirements for relevant 
TSPS/RTA items and compares these numbers with their respective 
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Fig. 2— Scope of OSTNPS program. 

capacities. If an exhaust occurs, the program prints out the operator 
node that is exhausted, along with the cause (s) of exhaust, and a 
complete status report on all other operator nodes. The user is given 
an opportunity to purchase new nodes, convert to TSPS No. IB, or to 
move traffic from one node to another. The program will proceed to 
the next study year only if there are no unrelieved exhausts. After 
completion of the last study year, the alternative is stored in a data 
base to be used by subsequent modules of OSTNPS. 

It should be emphasized that the user interacts with the program on 
a year-by-year basis while the program is running. It is not necessary 
for the user to know exactly what traffic moves and node purchases to 
make before the study begins. 

4.2.2 Description of exhaust causes 

The Node Exhaust program considers TSPS/RTA exhaust causes 
of several types. The most common type of exhaust for a TSPS No. 1 
is real time; with the development of TSPS No. IB and its associated 
increase in real-time capacity, a TSPS may exhaust owing to a number 
of other causes. Following is a description of other exhaust causes. 

4.2.2. 1 TLN terminations and individual trunk types. Various types of 
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Fig. 3 — Flowchart of Node Exhaust program. 

TSPS trunks terminate on Universal Trunk Frames (UTFs) which in 
turn attach to the Trunk Link Networks (TLNs). These trunk types 
include: incoming ("universal") trunks, Transfer Centralized Auto- 
matic Message Accounting (XCAMA) trunks, Base-remote (BR) 
trunks, and all other TSPS trunks considered as a single category. 6 
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A TSPS becomes TLN-exhausted if, after engineering each TLN 
trunk type and fitting these trunks on UTFs, the required number of 
UTFs (including an administrative margin) exceeds the hardware 
limitation. In addition, a TSPS can exhaust if one of the individual 
trunk types exceeds its software, design, or hardware limitation. 

4.2.2.2 PLN appearances and positions. The Position Link Networks 
(PLNs) contain terminations by which operator positions and various 
service circuits (receivers, outpulsers, announcement circuits, etc.) 
connect to the TSPS. As in the TLN case, a TSPS becomes PLN- 
exhausted if, after engineering positions and service circuits, the total 
number of PLN appearances exceeds hardware limitations. 

4.2.2.3 TSPS network. TSPS traffic travels between trunks requiring 
service and circuits/operators providing service via the TSPS network. 
A given trunk can connect to a given position or service circuit via one 
of eight paths composed of "A," "B," and "C" links. The TSPS network 
is limiting if its offered Erlang load is sufficiently great to result in a 
blocking probability greater than 0.001. 

4.2.2.4 TSPS office data memory. TSPS memory is subdivided into 
two types: the generic program and office data. Office data memory 
contains information specific to the design and traffic characteristics 
of a given TSPS site. Conversion of a TSPS No. 1 to a TSPS No. IB 
increases the total amount of addressable memory as well as real time. 

4.2.3 Input data 

The input data to the Node Exhaust program include, for each 
TSPS/RTA in the study area, base year requirements for various 
trunk types as well as current and forecast call volumes of various 
types. 

The following data are required: 

• Call volumes: trunk seizures, position seizures, and XCAMA trunk 
seizures 

• Trunks: base and RTA incoming trunks, XCAMA trunks, and all 

other trunks except BR 

• Real-time capacity in trunk seizures 

• Operator Average Work Time (AWT). 

4.2.4 Forecast of TSPS/RTA items 

For a given study year, the Node Exhaust program uses these input 
data to forecast TSPS/RTA items that determine exhausts. The 
program uses simple formulas or linear regressions in place of detailed 
calculations. 

Figure 4a shows a sample printout of these items from an actual 
study. At user request, this printout will appear in any study year 
while the Node Exhaust program is running. 
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Fig. 4(a)— Node Exhaust printout before user move— 1984. 

The following forecasts are made: 

• Real-time usage 

• Trunks of various types 

• Memory 

• Operator positions 

• Service circuits 

• TSPS network load. 

4.2.5 Exhaust prediction 

Once the above items are forecast in a given study year for every 
TSPS/RTA in the study, the program compares these numbers with 
their respective upper limits. The program thus determines for each 
TSPS/RTA whether it is exhausted and for what reasons. 

4.2.6 User-specified changes to network 

Input commands to the Node Exhaust program allow the user to 
purchase new operator nodes or move traffic from one node to another 
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Fig. 4(b) — Node Exhaust printout after user move — 1984. 



at any time. These steps are mandatory if there is an unrelieved 
exhaust; otherwise they are optional (as in the case of TSPS consoli- 
dation). The possible options are as follows: 

• The user may convert a TSPS No. 1 to TSPS No. IB. 

• The user may purchase a new TSPS or RTA. 

• The user may move TSPS or RTA incoming trunk seizures from 
one node to another. 

• The user may rehome an RTA from one TSPS to another. 

• The user may move XCAMA trunk seizures from one TSPS to 
another. 

• The user may retire a TSPS or RTA. 

If exhausts are still not relieved after such a series of steps, the 
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Fig. 5(a)— TSPS/RTA configuration before user move. 

program will not proceed to the next study year. The user must start 
over with the given study year and try another strategy. 

4.2.7 Example 

Figures 4 and 5 illustrate the results of a set of moves made during 
a run of the Node Exhaust program. Figure 4 lists the relevant forecasts 
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Fig. 5(b)— TSPS/RTA configuration after user move. 

before and after the moves, and Fig. 5 shows a pictorial representation 
of this situation. 

The study area consists of three TSPSs: TSP1, TSP2, and TSP3, all 
of which are TSPS No. l's. These are the columns in Figures 4a and 
4b. Each row represents a given forecast item for the study year, in 
this case, 1984. The tables are split into two sections: "User-Controlled 
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Items" (trunk seizures which the user may directly move from one 
operator node to another) and "Other Relevant Items" (exhaust-de- 
termining items which indirectly change as a result of such a move). 

To evolve from Fig. 4a to 4b, the user retires TSP3 in the following 
way. First, RTAs RTA5, RTA6, RTA7, and RTA8, presently homed 
on TSP3, are rehomed to TSP1. Second, RTAs NEW1, NEW2, and 
NEW3 are purchased, homed on TSP2, and loaded with all of TSP3's 
base incoming traffic. Finally, all of TSP3's XCAMA traffic is moved 
to TSP1, leaving TSP3 with no traffic and hence retired. The remain- 
ing TSPSs TSP1 and TSP2 exhaust real time as a result of the move, 
and they are converted to TSPS No lB's. 

4.2.8 Completion of run 

Once all years in the study period have been covered, the relevant 
information for the alternative is printed on the user's terminal. The 
information is also organized into an output database for use by the 
PSS and Network programs described below. 

4.3 PSS program 
4.3.1 Summary 

The main function of the PSS program is to establish a schedule for 
Position Subsystems (PSSs). This task can be separated from all 
others because its only input is the total required number of operator 
positions on each TSPS for each study year. Numbers of positions are 
established in the Node Exhaust program depending on incoming 
traffic to the TSPSs. Once the schedule is established, an additional 
task is to obtain facilities between each PSS and its home TSPS. 

4.3. 1. 1 PSS schedule. The schedule is determined by the following 
considerations: 

• Total number of positions required on each TSPS in each study 
year. 

• Equipment actually in the field in the base year. 

• The absolute and recommended maximum number of positions 
per PSS. 

• The type of PSS (PSSl or PSS2).* 

• Minimization of the number of PSSs in the study, subject to 
administrative constraints and operator availability. 

The solution consists in presenting to the user a schedule that is 
compatible with all the constraints, as in Fig. 6a, and letting the user 
modify it as desired by means of interactive commands, as in Fig. 6b. 

Following is a description of Fig. 6a. First, equipment in the field 



* PSSl positions are no longer being manufactured, and PSSls remain capped at 
their present position levels. 
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Fig. 6(a)— A first-order PSS field. 



TSPS1 
PS11* 
PS12 
PS13 

TSPS2 
PS21* 
PS22* 
PS23 



TSPS4 
PS41 
PS42 



1980 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 



55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 

30 18 23 27 30 30 30 30 30 30 30 30 30 30 28 30 33 35 38 40 43 

| 3 4 6 8 10 12 15 18 20 23] 

55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 

47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 
30 14 14 17 20 23 25 28 32 35 39 



TSPS3 

PS31* 55 55 55 55 00000000000000000 

PS32* 28 28 28 28 00000000000000000 

PS33 30 00000000000000000000 



00000000000 
00000000000 



50 50 50 50 50 50 50 
27 29 32 34 37 40 43 



Fig. 6(b)— PSS field after the first move. 

(base year) is entered by the user (1980 in this case). PSSl's, for which 
positions are capped, are marked with a "*". For the study years 
(1981-2000), the scheduler bases its calculations on position require- 
ments and purchases new PSSs where needed. 

Given this PSS schedule, the user can modify it with the following 
interactive commands: 

• For a given TSPS, the user may redistribute the number of PSS2 

positions. 

• The user may rehome a PSS2 from one TSPS to another. 
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• The user may or may not release unneeded PSS2 positions for 
reuse. 

Consider Fig. 6b. The first move consists in all excess positions 
beyond 30 in the base year being moved from PS12 to PS13 for all 
study years up to 1994. A possible second move consists of making 
PS33, PS13, and PS42 the same PSS by rehoming PS33 (originally 
homed on TSPS3) to TSPS1 in 1984, then to TSPS4 in 1994. 

4.3. 1.2 PSS facilities. Once the schedule is established, the program 
asks the user for facility data between TSPSs and the PSSs. This, 
together with the schedule, completely determines the input to the 
economic analysis program. 

4.4 TSPS/RTA Network program 

Besides the network joining TSPSs to PSSs, there is the network 
joining local offices and toll switches to TSPS/RTA's. This network 
can be divided into three distinct portions: 

• Toll connect trunks (local office to TSPS/RTA to toll switch). 

• Base remote trunks (RTA to TSPS). 

• Intertoll trunks. 

Figure 7b shows an example of such a network. 

The Node Exhaust program allocated total trunk seizures amongst 
the TSPS/RTA's without making any assumptions about the network. 
The separation of exhaust planning and network planning allows 
simplified program design, and allows the user to concentrate on each 
issue separately. The method used to model the network allows this 
separation to work; the network program guides the user through the 
steps of establishing the network corresponding to the alternative 
formulated by the Node-Exhaust program. 

At the beginning of the study, there is by definition a one-to-one 
correspondence between "local areas" and TSPS/RTAs (Fig. 7a). 
User-specified traffic moves made during a node exhaust run may 
affect the network in the following ways (see Fig. 7b): 

• A move of base-remote trunks, also called an RTA rehome (a) in 
Fig. 7b. 

• A move of toll-connect trunks (b) in Fig. 7b. 

• Changes in the intertoll network. A certain percentage of operator 
traffic leaving a local area must go back to the same local area via 
its toll switch. Corresponding to each toll-connect move (b) is an 
increase in required intertoll trunks (b'). No such intertoll adjust- 
ment is necessary for a base-remote move. 

The Network program obtains the following information from the 
user: 

• Toll switch information: names, types, homing TSPS/RTAs. 

• Base-remote mileage and facility information. 
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Fig. 7— (a) Relationship of local offices and toll switches to TSPS/RTA's— the 
correspondence is one to one. (b) Effect on network of user-specified traffic moves 
during a Node Exhaust run. 

• Toll-connect mileage and facility information, including the per- 
centage of 2- wire and 4-wire bridges. 

• Community of interest and intertoll mileage/facility information. 

4.5 Economic evaluation and translator programs 

Economic evaluation of the alternatives is performed by TASP, 
which has already been mentioned. Telephone company planners are 
very familiar with this program, which has been in use for years. TASP 
requires a considerable amount of input, even for studies involving 
only a few switches. A fourth program, the Translator program, tran- 
scribes the output of the three preceding programs into TASP format 
without user intervention. The PSS and TSPS/RTA Network pro- 
grams write files in a compact language which is translated into TASP 
language by the Translator program. 

V. RUNNING THE PROGRAMS 

The generation and economic evaluation of a complete alternative 
with OSTNPS involves the following steps to be taken by the user: 

• Run the Node Exhaust program. 

• For the above Node Exhaust program alternative, run one or a 
few appropriate PSS alternatives. 

• Run each of these PSS alternative through TASP and choose the 
best. 
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• Run the Network program for the above Node Exhaust program 
alternative. 

• Concatenate the best PSS alternative with the Network program 
alternative, and run this complete alternative through TASP. 

This TASP output constitutes the economic evaluation of this com- 
plete alternative, to be compared with others. 

VI. CONCLUSION 

OSTNPS is an operator services long-range planning tool. It allows 
the user to analyze in a short time different strategies of operator 
services network evolution. For high-growth areas, OSTNPS evaluates 
various types of load-balancing alternatives versus purchase of new 
equipment. For low-growth areas with underutilized nodes, OSTNPS 
helps the user determine whether or not to retire those nodes. For 
both of these cases, OSTNPS allows the user to easily incorporate the 
conversion to TSPS No. IB into the planning process. OSTNPS is not 
an optimizer, but instead lets users generate and evaluate their own 
alternatives. 
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